(1) Field of the Invention
The invention relates to parallel port device drivers. More specifically, the invention relates to the device driver which can be used to implement the IEEE 1284 bi-directional parallel peripheral interface standard.
(2) Related Art
Parallel port communications have been generally well-known for some time. Throughout the 1980's, a unidirectional parallel communication between hosts and printers or hosts and other peripheral devices was commonly used. This unidirectional mode of communication became known as Centronics.RTM. communications after the company which first introduced it, Centronics Data Computer Corporation. Centronics.RTM. is an 8 bit parallel unidirectional communication link between the host and a peripheral with data only flowing in a forward direction, i.e. from the host to the peripheral. Centronics.RTM. was so widely used, it became a de facto standard in the industry. Unfortunately, Centronics.RTM. suffers from one major shortcoming which limits its utility in a network environment, specifically, it is unidirectional It is also relatively slow.
Accordingly, as networks have become more prevalent, there has been a push in the industry to develop a standard method for bi-directional parallel communications between hosts and peripheral devices. In response to this push, IEEE has promulgated a standard signaling method for a bi-directional parallel peripheral interface for personal computers, IEEE 1284 specification ("1284"). The 1284 defines a signaling method for bi-directional parallel communications between hosts and peripheral devices. It is also asynchronous and fully interlocked. By virtue of the fact that there were a number of divergent interests in the working group preparing the standard, the standard defines five distinct modes of operation. Specifically, compatibility mode, nibble mode, byte mode, enhanced parallel port mode (EPP mode) and extended capabilities port mode (ECP mode) are all defined under the umbrella of a "single" standard.
Compatibility mode is basically the former Centronics.RTM. mode, which provides an asynchronous byte-wide forward (host to peripheral) channel with data and status lines used according to the prior definitions. Compatibility mode has the effect of making 1284 backward compatible.
Nibble mode is a peripheral to host unidirectional protocol which can be used in conjunction with compatibility mode for a full bi-directional interface. Data is transferred to the host four bits at a time over four control signals defined in the Centronics.RTM. parallel port. The nibble protocol employs a program input/output (PIO) interface to work with existing parallel port controllers. The data transfer rate is quite slow.
Byte mode is a peripheral to host unidirectional protocol which can be used in conjunction with compatibility mode for a full bi-directional interface. Bytes are transferred to the host over the eight data lines. Byte mode is twice as fast as nibble mode, but is still a PIO interface and, consequently, relatively slow. Moreover, the byte mode protocol required an expanded definition of the data lines from the existing Centronics.RTM. standard.
Expanded parallel port mode defines a bi-directional protocol in which bytes are transferred in either direction by an interrupt driven PIO interface. Either the host or the peripheral may fill a 4 byte buffer and await a signal to indicate the transfer was completed. While this mode is faster than byte or nibble mode, it is still an interrupt driven PIO which is relatively slow and has not gained wide acceptance.
Extended compatibility port mode is a high speed bi-directional protocol in which bytes are transferred in either direction by a DMA driven interface. This mode is the fastest and most efficient of the IEEE 1284 modes.
While the electrical signaling and cabling requirements for each mode are well-defined in the IEEE 1284 specification, and chip manufacturers have provided the hardware necessary to implement these various modes, the issue of 1284 device drivers has been largely ignored. Significantly, each mode defines a separate and distinct protocol with different signaling and phase requirements which would arguably justify implementing each protocol as a separate driver. However, because any single device must have only a single driver, the 1284 specification creates a unique problem of requiring the implementation of multiple distinct protocols within the single driver. This is particularly true given that the specification requires that to be 1284 compliant, a device must support at least compatibility mode and nibble mode.
A portion of the host kernel is the streams environment. The streams environment has many special requirements which are detailed in full in the Streams Programmer's Guide Sun OS 5.3 (1993). Particularly in the context of a 1284 device driver, a streams interface allows handshaking with upper level modules to provide effective coordination of data transfers. Additionally, the streams environment provides required support for ioctls making such ioctls available for use with the driver.
Therefore, it would be desirable to develop a device driver which is 1284 compliant and readily interfaces with the streams environment.